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SUMMARY 


The Langley Research Center (LaRC) project called Multipurpose 
User-Oriented Software Technology (MUST) is intended to reduce the cost of 
producing flight software and to provide an integrated system of support 
software tools for flight projects. One of the tools developed under this 
project was the Interactive Software Invocation System (ISIS) which allows a 
user to build, to modify, to control, and to process a total flight software 
systan without direct ccranunications with the host c^puter. ISIS was 
developed primarly for the handlir^ of lairge amounts of information that are 
typically required to support flight projects. In order to evaluate the 
effectiveness of the system as applied to a flight project, the collection of 
software components required to support the LaRC Annular Suspension and 
Pointing Systan (ASPS) flight project were integrated using ISIS. The ASPS 
project information was oi^anized vinder ISIS according to the software 
development life cycle concept. This resulted in an integrated systan adequate 
to perfonn the verification and validation requirements for the ASPS flight 
software code. This systan contains an ordered collection of information 
consisting of language processors, automated documentation and design tools, 
flight software utility routines, simulation subsystans, and testing procedi^es 
which are controlled throi:^h the interactive user interface capability provided 
by ISIS. 


This report discusses the ASPS software systan, the ISIS features, the 

organization of an ISIS library, and the integration of ASPS into ISIS. The 

5-level hierarchical file structure of ISIS proved to be very useful in 

organizing the ASPS flight software information in a more meaningful manner 
than allowed with the Network Operating Systan (NOS), but ISIS proved to be 
less efficient than NOS in the storing and retrieving of files. The 

Interactive Programming Language (IPL) capability is one of the strongest 
features of ISIS but one that requires a great deal of effort by a user to 
exercise it to the fullest extent possible. ISIS is still in the development 
with several improvements planned to enhance its value and usability. 


INIRQDUCriON 


The Langley Research Center Multipurpose User-Oriented Software Technology 
(MUST) project was designed to reduce the cost of producing software for 

digital systans used ia flight research by providing an integrated system of 

software tools for use throughout the flight software development process. The 
Int^rated Software Invocation Systan (ISIS), one of the MUST tools, is an 
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interactive data management systan providing the user with a file manager, text 
editor, a tool invoker, and an Interactive Programming Language (IPL). The 
basic file design of ISIS is a 5-level hierarchical structure. The file 
manager controls this hierarchical file structure and permits the user to 
create, to save, to access, and to purge pages of information,. The text editor 
is used to manipulate pages of text to be modified and the tool invoker allows 
the user to communicate with the host computer through a RUN file created by 
the user. The IPL is based on PASCAL and contains most of the statonents found 
in a high-level prc^ramming language. The IPL program is used to provide an 
interactive interface between ISIS and the user, permitting a user to interact 
with ISIS through a prompting process provided by the IPL. 


The Annular Stispension and Pointing Syston (ASPS) is under development to 
provide the improved pointing capability required for the Shuttle sortie 
missions. To support the software development of ASPS requires large 
quantities of infonnation consisting of documentation, design and 
Implementation tools, and testing procedvires. Determining how best to use and 
control this vast amount of Information led to evaluating the utility of ISIS 
and other software support tools developed vmder MUST as applied to flight 
projects. 


DISOJSSION OF THE ASPS SOFTWARE DEVELOPMENT 


The software development life cycle concept was followed in the 
organization of files for this flight project. The logical groupings for the 
various pieces of information in the ASPS flight system are as follows: 
documentation, design tools, implementation tools, and testing tools. 


The ASPS flight software documentation requirements consist of a Software 
Design Document (SDD) , Software Standards Document (SSD) , Software Requirements 
Document (SRD) , General Sof tware Development Test Plan (SDTP) , and Program 
Specifications Document (PSD) . 


Two design tools used in the development and debugging phases of the ASPS 
are a text processor and a structured flowcharter. The RNF text processor is a 
text formatting systan used to create machine acceptable text and to produce a 
readable version of docimentation in upper and lower case. It accepts 
free- format text files and produces output suitable for a terminal, a line 
printer, or a typewriter. The structured flowcharter is a flow diagramming 
tool for documenting and understanding programs. It produces flowcharts for 
programs written in the high-level language HAL/S. The flowcharts are 
presented in a top-down flow that can be used in the design, implementation, 
and debug phases of flight software. This systan can be used to produce 
flowcharts on either a printer or a plotter. 



The implementation tools consist of assemblers, loaders, canpilers, and 
cross-compilers. A META ASSEMBLER was used in the testing and the application 
of the ASPS simulators and in the assanbly of the actual ASPS flight code to 
produce an object module for processing. The object module is generated 
according to the machine definition for the ASPS flight computer which is input 
to the META ASSEMBLER. This code is input to a Linkage Editor creating a load 
module which may be executed on the target computer or by a simulator. The 
HAL/S cross-compiler and the ASPS simulators are written in PASCAL. 


The testing tools used for ASPS include simulators, a utility library, and 
test routines. The flight conputer supporting the ASPS was developed by IBM 
essentially as a flight qualified version of IBM System 360 and is called the 
NASA Standard Spacecraft Computer-II (NSSC-II). Since the I®SC-II computer was 
not available for the software development at LaRC, a NSSC-II Interpretive 
Computer Simulator (ICS) was developed to perfoim the verification and 
validation of the actual ASPS flight software. Currently, the ASPS flight code 
consists of a Real-Time Executive Module (RTEM) written in assembly language 
and an Attitude Control Module (ACM) and an Attitude Determination Module (ADM) 
written in HAL/S. Another of the testing tools is a closed- loop syston 
simulation consisting of the NSSC-II ICS and an ASPS Gmbal System (AGS) 
simulation. The simulation system also includes a utility support library, 
test routines, and test procediores necessary to assemble, ccmpile, link and 
load, and execute the ASPS flight software code. 


DISCUSS lOI OF ISIS 


- ISIS is an interactive data managanent systan which provides such 
capabilities as a file manager, text editor, and a tool invoker, each of which 
may be controlled by a PASCAL-based Interactive Programming Language (IPL). 
The file manager allows the user to access pages within a 5-level hierarchical 
structured file system. The text editor manipulates pages of text contained in 
the file system and the tool invoker allows communications with the resident 
operating system. An IPL program includes statements for text editing, file 
management, and tools invocation. 


ISIS was developed for the MUST project by Dr. W. Joseph Beiman of the 
University of Virginia. This systan was designed for machine independence and 
currently resides on the Langley Research Center CYBER series computers running 
under the Network Operating Systen (NOS). For an in-depth discussion of ISIS 
refer to the ISIS USERS MANUAL (ref. 1). 
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File Manager 


The ISIS file manager controls access to a 5-level hierarchical file 
structure as shown in figure 1. The highest level of this structure is the 
library. The library contains shelves, a shelf contains books, a book contains 
chapters, and a chapter contains pages* A N06 file is stored at the page 
level, the other four levels are used for naming convention only, allowing the 
user to identify each page of information. Pages may contain various types of 
information such eis documentation, source code, binary code, data, or control 
cards. All 5 levels of the file structure must be specified \^^ien first 
entering the library. The file structure is written in the form; 


1 ibrar y . shel f . book . chapter .page 


The user can access, save, and purge pages of information in the library 
through ISIS control statements. The USE statenent reads the contents of a 
specified page from the library into a specified work space called a frame for 
additional processing. The name of this page may be changed with the SET NAME 
statanent. The new page name can be saved or replaced with the SAVE or SAVE* 
statenent. The PURGE statanent eliminates the specified page frcxn the library. 
If the specified page is the only page in the chapter, the chapter will be 
eliminated. This process continues through the book and shelf level and an 
empty library will ramin. The library is never eliminated in this process, it 
must be purged from the systan by the iiser. 


Text Editor 


The ISIS editor is line oriented and not pointer oriented as are many text 
editors, therefore each line of text must be uniquely identified. The ISIS 
editor does this by assigning line numbers to each line of text . The^ numbers 
represent reference points for the specification of text by the editor. The 
text is referenced by designating the line of text to be modified within each 
coimand. The lines affected by the edit cotimand are referred to as the RANGE 
of the ccnmand which can be explicit or implicit. The explicit range permits 
the user to operate on everything vidthin a certain area of the page, the 
implicit range specifies a search of all lines in the text having a particular 
characteristic. The implicit and explicit ranges can be conbined, such as a 
particular characteristic between certain line numbers in the page. 


During editing a working frame is used as temporary storage. The frame 
can be a copy of an existing library page to be modified or it can be a new 
page entered by the user. There are 12 working frames available; the two 
frames WORK and SHOWN are pravided and named by the system, the other 10 frames 
must be named by the user. The ISIS editor permits the user to edit multiple 



frames simultaneously. The user can declaim a world.ng frai^ with the FRAME 
statement. This franie can then be declared ACTIVE and be viewed in 
with the LIST caimand. Text to be stored in this frame can e^r^ frOT the 
teiminal with the IFBERT command. The CHAN3E carmand will modify existing 
lines of text in the frame. The range of the CHANGE coimnd may consist^of ^ 
implicit or explicit range and specify the change be m^e in^a certain col^. 
The EXEC ccmmand peimits the user to execute the contents of the ACTIVE 
Portions of this frame can be executed by using the range option. Since 
are tonporary storage, it is necessary to SAVE the frame as a page in an ISIS 
libraxy using the ISIS file manager. 

The interrogation statanents give the user access to syst^ and 
prcgranming infonnation during an interactive session. For ex^ple, SHOW 
Sv® ^^ll display the ISIS reserved words and SHOW ABBREVS will display the 
current user declared abbreviations. 


Tool Invocation Statements 


' The tool invoker is made up of three statements. The RUN statement causes 
informtlon to be concatenated In a special sequence to to an ^eptable 
INPUT file that can be submitted to the host computer. INPUT file 

contains control cards, source programs, and/or data with a ^^^ht ^enthesis 
[)] used to separate each record. The file is referred to as a RIM file 
ISIS and RFILE in NOS. The SEND statenent allows the user to submit the RUN 
file to the NOS batch system. The STOP: SEND statanent is used for ^ 
interactive session. The STOP statement teiminates an ISIS session and the 
SEND statement submits the RUN file to the host operating system interactively. 


Interactive Programming Language 


The Interactive Programming Language (IPL) is based on the Mgh level 
language PASCAL. The user corimunicates with ISIS ttoough "caimnds ,^se 
coim^s can be user activated or activated through an IPL program. A ccmmand 
is defined as a sequence of one or more statanents with the number of ccrmnds 
in an IPL program depending on the user's needs. The stat^nts c^ be 
at the terminal and executed as a one time only interactive session or sto^ 
as a page in ISIS for repeated executions. The user can write . IPL 
to build a set of control cards, another IPL program to submit the ^ntrol 
cards to NCS with specified inputs, and still another program to edit the 
control cards. Without the IPL programs the. user woi^d build the control c^ds 
with the INSERT statement, edit them with the editing statenents (CHANGE, 
DELETE, MCDIFY, ADD) , and send them to NOS with the RUN and SEND statements. 
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The IPL differs fron PASCAL in that it does not require a BEGIN and END to 
surround compound statonents (all that is required is an END statement for 
termination of compound statanents) nor does it allow array packir^, CASE 
statements, or subrange types. The IPL allows some PASCAL data types in an 
abbreviated form such as INT and BCXIL. ISIS includes two data types not in 
PASCAL: STRING and KEY. The STRING contains alphanumeric information enclosed 
in quotation marks. KEY is defined as a line number assigned to each line of 
text. The line number can be any type of KEY operand, a KEY variable or 
expression, or a simple number. The KEY type permits the user to define 
variables to be used in the range of the edit commands. 


The two groups of programming statonents are the Declarative statanents 
describing the program variables, and the Action statements vhich are the 
executable statanents. The Declarative statanents are ABHIEV, TYPE, VAR and 
ERASE. The ABHIEV statement permits the user to abbreviate the ISIS statement 
verbs. The TYPE and VAR statements are similiar to the TYPE and VAR statements 
of PASCAL which declare various data structures and variables, respectively. 
If the user fails to declare all variables being used, instead of aborting the 
ccmmand,, the ISIS syston will interrelate the user. The ERASE statement 
eliminates the specified t 5 ^s and variables fron the identifier table. The 
Action statanents include an assignment statement and control statanents such 
as LOOP, REPEAT UNTIL, WHILE, KE, and IF-THEN-ELSE. The compile and execute 
stat^ents include XEQ and EXEC. XEQ takes the contents of a string expression 
and interprets it as a ccmmand to the system, the EXEC statanent allows the 
user to execute an ACTIVE or specified frame. The ASK, PRINT and PRINTLN 
statanents are interactive terminal input/output statanents. The ASK statanent 
will interrupt program processing and prompt for terminal input. The PRINT and 
PRINTLN statanents print terminal output. 


APPLYING ISIS TO ASPS 


The purpose of this case study was to assanble an integrated systan of 
existing software tools using the Interactive Software Invocation Systan (ISIS) 
for the suppxort of the Annular Suspension and Pointing Systan (ASPS) software 
development. The number of files (documentation, soinrce, binary, data, and 
test case) required to support the ASPS flight project is large. These files 
are stored in NOB as shown in figure 2 with no special organization. ISIS 
gives the user the capability of organizing these files in a library. The 
organization of a library is a task requiring a great deal of thought. For 
example, it was decided to organize the ASPS files according to the software 
development life cycle concept. One alternative to this would be to group 
files along functional lines. Files should be grouped into proper categories 
and each category should have a meaningful name. In the 5- level hierarchical 
file structure all information is stored at the page level and the ranaining 
four levels are used for naming convention only. Each level name has a maximum 
of seven characters. 
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Library For ASPS Tools 


The ASPS library oi^anization is based on four software develoFKient life 
cycle categories: documentation, design tools, implementation or coding, and 
testing. These four categories became the shelf labels for the ASPS^ library 
ASPSLIB as shown in . figure 3. The documentation (EXXMNT) shelf contains books 
labelled Software Design Document (SDD) , Software Standards Document (SSD) , 
Software Developnent Test Plan Document (SDTP), and Software Requirements 
Document (SRD) . The SRD book contains chapters of actual flight software 
modules labeled Real-Time Executive Module (RTEM) , Attitude Control Modi^e 
(ACM), and Attitude Determination Module (ADM). The RTEM chapter contains 
pages labeled Table of Contents (TC) , section I (I), and so forth. These pages 
contain the actual infoimation stored into this library. The tools (TOOLS) 
shelf contains a similar type organization for the design tools with books 
labeled Flowcharter (FLOWCHT) and Wordprocessor (WEIDPROC). The FLDWCHT book 
contains chapters labeled HALS programs (HALS), control cards (CONTROL), input 
(ILFT), and information (INFO). The CONTROL chapter contains pages labeled 
HALCAL, HALRRTR, and HOS. The HAIXAL page contains the control cards necessary 
to produce a CALOOMP flowchart, the HALPRTR page contains the control cards 
necessary to produce a printed flowchart, and the BK3S page contains the 
necessary control cards to compile the flowcharter source pregram. This type 
of organization can be applied to any project and can consist of a larger or 
smaller number of shelves, books, chapters, and pages. Figi^e 4 shows an 
©xQinpl© of £i lit)P9.ry Ifiiyoiit for th© Torniins.! Oonfigui*©d V©hicX© (TCV) flight 
project based on a functional organization. The flight project was organized 
into the three functional processes: flight controls, navigation and gxiidance, 
and displays labelled FLIGHTCTL, NAVGUID, and DISPLAYS, respectively. These 
three functional processes form the shelf level . The book level requires the 
same type, but distinct, books for each shelf. That is, each shelf requires 
its own REQUIREMENTS book, its own TEST PLANS book, and so forth. Tie 
REQUIREMENTS book contains the AUTOLAND chapter. The AUTOLAND chapter contains 
the LATERAL, LONG, FLARE, and ROLLOUT pages. 


Figures 5 throigh 7 show the layout of the library ASPSLIB. The^ design 
tools were organized into a TOOLS shelf as shown in figure 6. This shslf 
(TOOLS) will be used to show the process required for a library organization. 
The TOOLS shelf contains three books, the first book contains all pages 
associated with the flowcharter, the second book contains all pages associated 
with the RNF text processor, and the third book contains general information 
about the TOOLS shelf. The flowcharter book contains four chapters. The first 
chapter contains pages of flowcharter source, binary, and HAL/S grammar to 
flowchart a HAL/S program. The second chapter contains pages of control cards 
required to execute the flowcharter and produce plots in printed or plotted 
form. The third chapter contains pages of input (HAL/S programs), and the 
fourth chapter contains descriptive infoimation about the contents of the 
FLOWCHT book on this shelf. The page level contains the actual files as they 
were originaliy stored on NOS. These files include source pregrams for the 
flowcharter, binary files for the flowcharter and RNF, a HAL/S grammar for the 
flowcharter , input files for the flowcharter and RNF , output files for RNF , and 
control cards required to execute the flowcharter and RNF. 
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Library Directory Utility 


In addition to the four shelves described above, ifiPSLIB contains an 
additional shelf called GENEEIAL containing information about the contents of 
ASPSLIB. This library directory was built for the purpose of guiding a user 
through the ASPSLIB library and it is stored as pages in ASPSLIB. Figure 8 
shows the ISIS data base for ASPSLIB and the arrows indicate the dir^tion of a 
particular library walkthrough. Figures 9 through 13 show the information 
contained in the directory at each level of the library for this example and 
the steps necessary to move through each level. Within the library ASPSLIB, 
the DCCMNT shelf was selected for this example walkthrough, from this shelf the 
SRD book was selected, from this book the RTEM chapter was selected, and from 
this chapter the II page was selected. The actual library walkthrough begins 
with an information file at the library level as shown in figure 9. This 
information file can guide a user to any part Of the library without havir^ to 
know all the ISIS commands. The first entry into the library requires that all 
5-levels be specified. The ISIS command USE reads the contents of the "file" 
page into an active frame. The LIST:NK lists the contents of the active frdme 
without line numbers (KEYS) to the left of the text. The contents of this 
frame gives the user a brief description of the library, shows the shelf levels 
available and tells how to access the shelf of interest. The IXXllNT shelf w^ 
chosen as the next area of interest in this walkthrough. The next step is the 
shelf level as shown in figure 10. To access this level the user only needs to 
specify 4 levels. The contents of this frame describes the books avn;iiabie oh 
this shelf. The SRD book was chosen as the next area of interest. To access 
the book level the vser only needs to specify 3 levels as shown in figure 11 . 
The contents of this frame describes the chapters available in this book. The 
RTEM chapter was chosen as the next area of interest . To access the chapter 
level the user only needs to specify 2 levels as shown in figure 12. The 
contents of this frame describes the pages available in this chapter. The II 
page was chosen as the next area of interest and is shown in figure 13. The 
page level contains the actual page (file) of information stored in the 
library. 


Sutmit File Utilities 


Figure 14 shows a specific ISIS submit file contained in ASPSLIB which 
differs frcm a NOS submit file in the following ways. For ISIS the /JOB has 
been deleted and the EOF has been replaced by a right parenthesis [)J . The 
IFETCH and ISISGET are required by ISIS to retrieve binary file^ arid source 
files , respectively . Each file retrieved frdri ISIS must be specified in this 
manner. Even if two pages are in the Siamd cHapter all 5 levels must be 
specified. This submit file will compile and' execute the specific input file 
(ASPSl) specified in lines 9.1 and 13. The ISTCHE and ISISPUT stores or 
replaces binary files and source files, respectively. The RUN cotinand creates 
an input file (control cards and source program) to submit to NOS. The KEYS or 
line numbers are removed for NOS submittal using the no key (NK) parameter with 
the RUN command. The SEND command submits this RUN file to NOS. 



An ISIS IPL prc^am can be very xiseful in accessing pages from the file 
manager, with the capability of editing and replacing these pages, then writing 
the control cards necessary to submit this infonmtion to the host computer for 
execution. Figures 15 through 17 show an IPL prc^ram built to execute a 
general purpose submit file, the general purpose submit file to be executed, 
and the pranpting process for executing this IPL prc^ram. Figure 15 shows an 
IPL prc^ram that erases and assigns frames and variables, prompts the user for 
another job, and clears the RUN file. The user must specify the submit file 
needed for a general purpose submit. The program will prompt the user for the 
source page (input) name. When the source page has been assigned the program 
will ASK if you are ready to SEND. The IPL program will then loop and prompt 
for another submission. The general purpose submit file as shown in figure 16 
is the submit file from ISIS shown in figure 14 - edited for a variable input 
file. The ASPSl page was not retrieved nor was it specified as input on the 
PASCAL line. This submit file was built for variable inputs but only one input 
file is permitted for each submission. Execution of an IPL program showing the 
actual prompting process of an IPL program is shown in figure 17. The lower 
case type in figure 17 are the user's response to the IPL prompts. The program 
prompts the user for a job, clears the RUN file, inserts the submit file 
requested (as shown in figure 16), requests the source page name, shows the 
number of lines inserted, and ASKs if the user is ready to SEND the file to 
NOS. 


NOS files must be edited and submitted manually. Retrieving and storing 
files in the NOS system requires less effort on the part of the user and 
currently is much more efficient than ISIS. Seme differences in the ISIS text 
editor and the NOS text editor are noteworthy. The ISIS text editor is line 
oriented and the NOS editor is pointer oriented. The commands in both editors 
can be abbreviated requiring fewer key strokes for the user. The abbreviations 
are the default in NOS, in ISIS the user must define the abbreviations and 
these abbreviations can be geared to each user's wishes. The NOS editor can 
create or process an ASCII (upper and lower case) file. The ISIS editor has 
limited capability in this area. The NOS editor autonatically changes all 
occurrences on the line of text, ISIS changes only the first occurrence unless 
the multiple occurrence option is selected. In ISIS, KEYS are required for 
editing and are shown in figure 18 with the smallest possible incranent. 


OONO.UDING REMARKS 


This case study resulted in an organized file system containing existing' 
flight software development and support tools. This system is an integrated 
file system capable of supporting the verification and validation requiranents 
of the ASPS flight code. The 5-level hierarchical file structure of ISIS is 
extremely useful^ i and ordering pieces of information to be stored 
at each level. The capability of organizing files in this manner can be more 
valuable to a user than the Network Operating Systan (NOS) organization for 
lai^e amounts of information. Files are stored randomly in a NOS catalog as 
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shown in figure 2; whereas, in ISIS the organieation is controlled by the \aser 
as shown in figure 3. 


This paper reflects the state of ISIS at the time the case study was 
conducted in mid 1980. Since ISIS is still in the development and 
implementation phase, several desirable features are planned to be installed as 
demand requires and time allows. For example, procedures, functions, and a 
directory editing capability are presently being implemented. The directory 
editing is necessary for the editing of a library layout. Currently, if an 
error is made in any of the names \s^ile storing pages into the library this 
erroneous name will ronain in the library until the user purges this page and 
stores it again. Also, when a new page is stored into the library this new 
page automatically falls to the bottom of the chapter level. At present there 
is no capability for storing a page in a particular location. After the 
initial library in ISIS has been built if the user wishes to change the name of 
a pag e or store several additional pages, the ISIS library layout b^ins to 
look as though it has the same type of organization as a NOS catalog. With 
directory editing this could be avoided and the user would have the capability 
of storii:^ a page of information at any level in the library. This editing 
capability should enable the user to have a clean and well organized library at 
all times* 


An IPL program can be built that will control the file manager, text 
editor, and tool invoker. This allows the i;tser to access a page of information 
frqm the file manager, edit and replace this page, and then sutmit it to the 
host computer through an IPL progiwi* This is an advantage over the use of a 
set of independent tools required to perform the same task. The IPL programs 
must be built by saneone with considerable knowledge of ISIS, the host 
operating syston, the use of terminals, and the PASCAL language. If an IPL 
program has been built for a user by an ISIS syst^ builder then the user is 
only required to know how to use a terminal and have minimum knowledge of the 
host operating system to perform the same task. 


In conclusion the 5-level hierarchical file structure of ISIS was 
extremely useful in organizing the software components required for the ^PS 
flight project. This type of organization proved to be more meaningful than 
the NOS organization, but in the storing and/or retrieving of files ISIS proved 
to be less efficient than NOS. One of the strongest features of ISIS is the 
IPL capability, but it is one that requires a great deal of effort and systan 
knowledge by the user to exercise to the fullest extent. ISIS is still in the 
development and implementation phase mth several improvements planned to 
enhance its usability. 


Laigley Research Center 

National Aeronautics and Sp>ace Administration 
Hampton, VA 23665 
December, 1980 
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Figure 2. - Listing of ASPS files as stored under NOS 
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Figure 3. - Example ISIS data base for ASPS flight project 
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Figure 4. - Example ISIS data base for TCV flight project 
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Figure 5. - ASPSLIB Xibrary layout 
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Figure 6. - ASPSLIB library layout (continued) 
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Figure 7. - ASPSLIB library- layout (concludfed) 
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library walkthrough 





use aspslib. general .library.info.file;list :nk 

WORK USED FROM ASPSLIB. GENERAL. LIBRARY. INFO.FILE 

1 


This library consists of a collection of files required to 
support the ASPS flight project. These files include ASPS 
documentation, design tools, coding aids and testing systems. To 
access the area of interest enter one of the following commands. 

USE DOCMNT. GENERAL. INFO. TC; LIST :NK 

USE TOOLS. GENERAL. INFO. TC;LIST:NK 

USE CODI NG . GE NER AL . INFO . TC ; LI ST : NK 

USE TESTING. GENERAL. INFO. TC;LIST:NK 


NOTE 

The above commands must be explicitly designated to move from one 
area of the library to another. Take note as this will be the 
ONLY appearance of these commands. 

To exit ISIS enter STOP 


Figure 9. - Library level 



use docmnt. general. info. tc;list:nk 

WORK USED FROM ASPSLIB. DOCMNT. GENERAL. INFO.TC 

1 


This shelf contains information on ASPS documentation. To access 
the area of interest enter one of the following commands. 

(for Software Design Document) 

USE SDD.REF.TC;LIST:NK 

(for Software Standards Document) 

USE SSD. REF. TC; LIST :NK 

(for General Software Development Test Plan) 

USE SDTP.REF.TC;LIST:NK 

(for Software Requirements Document) 

USE SRD.INFO.TC;LIST;NK 

(for Program Specifications Document) 

USE PSD. INFO.TC; LIST :NK 

(for Module Test Plan Document) 

USE TSTPLAN.INFO.TC;LIST:NK 

(for Simulation) 

USE SIMULAT.INFO.TC;LIST:NK 


To exit ISIS enter STOP 


Figure 10. - Shelf level 



use srd.tnfo.tc;list:nk 


WORK USED FROM ASPSLIB.DOCMNT.SRD>INFO,TC 

1 


This book contains a general document on the ASPS Software 
Requirements and specific documents for the Real-Time Executive 
Module, Attitude Control Module, and the Attitude Determination 
Module. To access the area of interest enter one of the 
following commands. 

(for ASPS Software Requirements) 

US E R EF . AGSSR D ; LI ST : NK 

(for Real-Time Executive Module) 

USE RTEM.TC;LIST:NK 

(for Attitude Control Module) < 

USE ACM. TC; LIST :NK 

(for Attitude Determination Module) 

USE ADM.TC;LIST;NK 


To exit ISIS enter STOP 


Figure 11. - Book level 



use rtem.tc;list :nk 

WORK USED FROM ASPSLIB.DOCMNT.SRD.RTEM.TC 

1 


This chapter contains the Table of Contents for the Real-Time 
Executive Module document. 

6.0 MODULE REQUIREMENTS 

6.1 Real-Time Executive Module 


The Real-Time Executive Module shall provide the following 
operating system functions for the AGS software: 


6.1.1 (I). 

6.1.2 (II) 

6.1.3 (III) 

6.1.4 (IV) 

6.1.5 (V) 


Program Load 

Program Initialization 

Interrupt Processing (with error 
detection) 

Program Task Scheduling 
I/O Data - Timing and Control 


To access enter one of the following commands. 


USE I;LIST:NK 
USE il;LIST:NK 
USE III;LIST:NK 
USE IV;LIST:NK 
USE V;LIST:NK 
To exit ISIS enter STOP 


Figure 12 


- Chapter level 



use ii;list:nk 

WORK USED FROM ASPSLIB.DOCMNT.SRD.RTEM.il 

1 


1 


6.1.2 Program Initialization 


The program initialization section will provide 
initialization of the AGS software immediately following program 
load. This mode shall initialize the Program Status Words 
(PSW's), set the storage protect keys, set up Buffered I/O, 
initialize the Real-Time Executive variables and zero the Real 
Time Clock. In addition, it will perform data and filter 
initialization for the designated functions listed in Table 
6.1.2. When the initialization is complete, the NSSC-II will 
interrupt the DEA to inform it of its status and enter the 
"wait-state”. Real-time processing will not begin until the DEA 
generates an interrupt to start the first real-time cycle. 


Figure 13. - Page level 



use aspslib.testlng.system.control .nsscii ;list 

ASPSLIB. TESTING. SYSTEM. CONTROL. NSSCII USED AS WORK 

l'. =NSSCII,T200,CM77000. RM 1115 M.S. NOLAND 

2. sUSER, 

3. =CHARGE, ,LRC. 

l|. =«ICS COMPILE AND EXECUTE RUN 

5. =ATTACH,ISTORE,IFETCH,ISISPUT,ISISGET/UN= 

6. =ATTACH, PASCAL, PASCLIB/UNrLIBRARY. 

7. =IFETCH,CKPTF. ASPSLIB. TESTING. ICS. INTEGRT.CKPTF 

8. =ISISGET,DATAF3. ASPSLIB. TESTING. ICS. INTEGRT.DATAF3 

9. rISISGET.CONTRLF. ASPSLIB. TESTING. ICS. INTEGRT.CONTRLF 
9.1 =ISISGET,ASPS1. ASPSLIB. TESTING. ICS. INTEGRT.ASPS1 

10. =REWIND,DATAF3,CONTRLF,CKPTF. 

11. =RFL, 77000. 

12. =REDUCE,-. 

13 . =PASCAL,ASPS1. 

11«. =LGO,,,DATAF3. 

15. =IST0RE,LG0. ASPSLIB. TESTING. ICS. INTEGRT.LGOO 

16. rISTORE.CKPTF. ASPSLIB. TESTING. ICS. INTEGRT.CKPTF 

17. =ISISPUT,CONTRLF. ASPSLIB. TESTING. ICS. INTEGRT.CONTRLF 

18. =) 

USE ASPSLIB. TESTING. SYSTEM. CONTROL. NSSCII 

RUN;NK 

SEND 


Figure 14. - Specific submit file 



use aspslib. testing. system. nsscil .exec;list 


WORK 

1 . 

2 . 

3. 

H. 

5. 

6 . 

7 . 

8 . 
9 . 

10 . 

11 . 

12 . 

13. 

14. 

15 . 

16. 

17 . 

18. 
19. 
20 ;. 


USED FROM ASPSLIB. TESTING. SYSTEM. NSSCII. EXEC 
sERASE W0RK1; FRAME WORK1 : STRING; 
sERASE SI; VAR S1;STRING; 
sERASE S; VAR S;STRING; 

=ERASE SND; VAR SNDrSTRING; 

=LOOP 

= ASK SI, • DO YOU WANT TO EXECUTE ANOTHER JOB? <Y>OR <N> '; 
r IF (S1 = 'Y') OR (St=‘YES») THEN CLEAR RUN; 

= W0RK1/USE ASPSLIB. TESTING. SYSTEM. CONTROL. NSSCII 

= W0RK1/RUN:NK 

= ASK S, 'SOURCE PAGE NAME?' 

= EXITIF S='NONE'; 

= XEQ CAT CW0RK1/USE ',S); 

= WORK 1 /RUN; NK 

= ASK SND, 'READY TO SEND?'; 

= IF (SND ='YES') OR (SND='Y') THEN SEND; 

= ELSE PRINTLN ' DID NOT SEND ' ,S; 

= END 

= END; 

= EXITIF ST='N'; 

=END; 


Figure 15. - An IPL program 
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use aspslib. testing. system. control .nsscii ;list 


ASPSLIB. TESTING. SYSTEM. CONTROL. NSSCII USED AS WORK 

1. =NSSCII,T200,CM77000. RM 1115 M.S. NOLAND 

2. rUSER, 

3. rCHARGE, ,LRC. 

l|. =»ICS COMPILE AND EXECUTE RUN 

5. =ATTACH,ISTORE,IFETCH,ISISPUT,ISISGET/UN= 

6. rATTACH, PASCAL, PASCLIB/UN=LIBRARY. 

7. =IFETCH,CKPTF. ASPSLIB. TESTING. ICS. INTEGRT.CKPTF 

8. =ISISGET,DATAF3. ASPSLIB. TESTING. ICS. INTEGRT.DATAF3 

9. =ISISGET,CONTRLF. ASPSLIB. TESTING. ICS. INTEGRT.CONTRLF 

10. = REWIND, DA TAF3,CpNTRLF,CKPTF. 

11. =RFL, 77000. 

12. sREDUCE,-. 

13. = PASCAL. 

111. =LGO,,,DATAF3. 

15. =IST0RE,LG0. ASPSLIB. TESTING. ICS. INTEGRT.LGOO 

16. rISTORE.CKPTF. ASPSLIB. TESTING. ICS. INTEGRT.CKPTF 

17. rISISPUT.CONTRLF. ASPSLIB. TESTING. ICS. INTEGRT. CONTRLF 

18. =) 


Figure 16. - General submit file 



use nsscll.exec;exec 


ASPSLIB. TESTING. SYSTEM. NSSCII. EXEC USED AS WORK 
DO YOU WANT TO EXECUTE ANOTHER JOB? <Y> OR <N> y 

RUN CLEARED. 

ASPSLIB. TESTING. SYSTEM. CONTROL. NSSCII USED AS WORK1 
25 ITEMS IN SPECIFIED RANGE. 

SOURCE PAGE NAME? ics.integrt .aspsi 

ASPSLIB. TESTING. ICS. INTEGRT.ASPSl USED AS WORK1 
1»258 ITEMS IN SPECIFIED RANGE. 

READY TO SEND?y 

"ATCYNGA” SENT TO BATCH. 

DO YOU WANT TO EXECUTE ANOTHER JOB? <Y> OR <N> n 


Figure 17. - Execution of an IPL program 



use aspslib .docmnt .ssd .ref .tc ; list 

WORK USED FROM ASPSLIB. DOCMNT. SSD. REF. TC 

0.001=1 
0 . 002 = 

0.003= 

0 . 00 »» = 

0.005= 

0.007= This book contains the Table of Contents for the Software 


0.008= 

0.009= 

Standards 

Document. 


0.01 = 
0.011= 
0.012= 


TABLE OF CONTENTS 


0.013= 

0.011»= 

I 

Introduction 
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0.015= 

0.016= 

II 

Requirements Document 
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0.017= 

0.018= 

III 

Program Specification 
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0.019= 
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IV 
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Figure 18. - A page of documentation in ASPSLIB 
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